1. Field of the Invention
The present invention relates to a centralized supervisory system for supervising transmission network elements and a method of supervising transmission network elements, and more particularly to a system for and a method of centralized supervision of a transmission network with sets of supervisors (SVs) and a plurality of supervisors in each set for supervising a number of transmission network elements and a central supervisor (CSV) connected to the supervisors.
2. Description of the Prior Art
There is generally known a centralized supervisory system having a plurality of supervisors (SVs) for supervising respective transmission network elements scattered in remote locations and connected respectively to the supervisors, and a central supervisor (CSV) for collecting supervisory data from the supervisors and processing the supervisory data for efficient network maintenance. The central supervisor usually comprises a minicomputer or a workstation for achieving high-level processing operation.
The minicomputer or workstation has a highly sophisticated human interface device which can display more specific supervisory data including the type of a fault that has occurred, a network element that is subjected to a fault, and a network region or zone in which a fault has occurred, than conventional LED devices. The minicomputer or work station also makes it possible to manage supervisory data as by statistically processing supervisory data. For such supervisory data management, it is necessary to obtain history data that are higher in level than conventional fault data called a "log".
One conventional centralized supervisory system is shown in FIG. 1 of the accompanying drawings. The conventional centralized supervisory system comprises a tree-type hierarchical network having a number of slave supervisors (SSVs) connected respectively to transmission network elements (NEs), a number of master supervisors (MSVs) each connected to some of the slave supervisors, and a central supervisor (CSV) positioned at the top of the tree structure and connected to the master supervisors (MSVs). Information as to a fault that has taken place in any transmission network element (NE) is sent successively through the corresponding slave supervisor (SSV) and the corresponding master supervisor (MSV) to the central supervisor (CSV). Each of the transmission network elements (NEs) has a built-in processor for diagnosing itself for a fault, and transmits diagnostic data through a built-in supervisor to the corresponding slave supervisor (SSV). The slave supervisors (SSVs) and the master supervisors (MSVs) collect and transmit the diagnostic data to the central supervisor (CSV). The slave supervisors (SSVs) and the master supervisors (MSVs) primarily serve to collect and transmit data though they slightly process the collected data. The central supervisor (CSV) supervises the transmitted fault data and manages the entire system.
In recent years, the supervisory area of a central supervisory system has been spreading from local urban regions to a national stage. The widespread supervisory service has resulted in many supervisory bases or footings and a hierarchical centralized supervisory system configuration, and demands a plurality of centralized supervisory systems put together for higher reliability.
To meet such a demand, there has been proposed a larger-scale centralized supervisory system having two tree configurations as shown in FIG. 2 of the accompanying drawings. In the illustrated centralized supervisory system, fault data is transmitted from a slave supervisor (SSV) through a master supervisor (MSV) to an extensive supervisor (XSV), from which the fault data is supplied to a zone center (ZC) and a national center (NC). The zone center (ZC) effects centralized supervision of those transmission network elements that are disposed in a zone to which the zone center (ZC) belongs. The national center (NC) supervises all the transmission network elements across the zones.
The conventional centralized supervisory system is, however, disadvantageous for the following reasons:
1. Fault data and other data in each zone are supplied to the national center (NC), but not to the other zones. Therefore, in the event of a fault with a transmission network element in one zone adversely affecting lines connecting the fault network element to the transmission network elements in other zones, those zone centers (ZC) of the zones that are connected to the adversely affected lines can recognize the malfunctioning of the lines, but cannot identify the position of the fault and hence cannot take an appropriate action.
2. When the national center (NC) malfunctions due to a fault, the zones are detached from each other, and the zone centers (ZC) effect centralized supervision of their own zones, respectively. Consequently, the ability of the system to supervise the transmission network elements all across the zones is disabled.
3. The number of zones that can be supervised by the national center (NC) depends on the number of input ports possessed by the national center (NC). Therefore, the number of zones that can be added is limited, and the entire system cannot be expanded beyond a certain limit.
The central supervisor (CSV) and the transmission network elements (NEs) supervised thereby are connected by dedicated communication lines, over which fault data are transmitted from the transmission network elements (NEs) to the central supervisor (CSV). The fault data include current data indicative of the current status of the transmission network elements (NEs), and event data indicative of only a change in the current status after the previous status has been transmitted from the transmission network elements (NEs) to the central supervisor (CSV). The central supervisor (CSV) receives the fault data as a communication message, and collects and manages the received fault data.
For the sake of brevity, the flow of such a communication message will be described below as a flow from an XSV to a CSV which may be an NC or a ZC. Specifically, the XSV collects communication messages from NEs through SSVs and MSVs, and then sends the collected communication messages to the CSV. Here, the transmission of a communication message from the XSV to the CSV will be described by way of example. The flow of a communication message between the NEs, the SSVs, the MSVs, and the XSV will not be described below unless particularly necessary.
For collecting fault data by way of the flow of a communication message from the XSV to the CSV, the following three alternative time sequences may occur when the XSV and the CSV are started:
1. The XSV side is set up first, and thereafter the CSV side is set up.
2. The CSV side is set up first, and thereafter the XSV side is set up.
3. The CSV side is set up first, then the XSV side is set up, thereafter disabled, and then set up again.
The flow of fault data between the XSV and the CSV will be described below with respect to the above three time sequences. The time when the XSV side and the CSV side are set up is the time when they are energized with electric power supplied thereto, and the setting-up is completed upon elapse of an idle time (setting-up time) in which data loading, initialization, transmission of a request for current data, and reception of transmitted data are carried out. When the setting-up is completed, the XSV and the CSV are ready to supervise the NEs. The setting-up of the XSV side includes the setting-up of the XSV, the SSVs, the MSVs, and the NEs.
FIG. 3 of the accompanying drawings is a timing chart of the first time sequence referred to above in which the CSV side is set up subsequently. A CSV 70 has a current table 74 indicative of the contents of faults at times, and history data 75 indicative of the histories of the respective faults. In reality, there are several thousand to several ten thousand NEs, and hence there are a considerable number of contents of faults and the history data 75 are composed of a large number of fault data. However, it is assumed for simplicity that there are three faults A, B, C and there are fault data with respect to the faults A, B, C.
As shown in FIG. 3, the XSV 60 side is set up, subjected to a fault A at a time t0, then restored from the fault A at a time t1, and subjected again to a fault B at a time t2. During this time, the CSV 70 side has not been set up, and fault data from the SSVs and the MSVs are stored in a buffer memory of the XSV 60.
Then, when the CSV 70 side is set up, the CSV 70 clears all the contents of the current table 74, writes "RESTORED" in the current table 74, and issues a request command to request current data from the XSV 60. In response to the request command, the XSV 60 sends current data 81 representing current data (B occurred, restored from A, C at t2) to the CSV 70. Based on the supplied current data 81, the CSV 70 produces a current table 74 and also history data 84 with respect to the fault B. Then, the XSV 60 transmits stored event data 82 to the CSV 70. Based on the transmitted event data 82, the CSV 70 generates data indicating occurrence of and restoration from of the fault A, and also data indicating occurrence of the fault B, in the current table 74. The occurrence of and restoration from the fault A are indicated within a rectangular frame 83 in the current table 74. Then, the CSV 70 generates, as the history data 75, history data 85 corresponding to the occurrence of and restoration from the fault A and history data 86 corresponding to the occurrence of the fault B.
One problem with the above first time sequence is that the two history data 84, 86 are generated with respect to the fault B. Another problem is that the setting-up of the CSV 70 is delayed while the current table 74 is being updated with the occurrence of and restoration from the fault A, and since there are many NEs actually, large event data are stored in the buffer, and the idle time (setting-up time) of the CSV 70 side is considerably long.
FIG. 4 of the accompanying drawings is a timing chart of the second time sequence referred to above in which the XSV side 60 is set up after the CSV 70 side.
As shown in FIG. 4, the CSV 70 side is set up, clears all the contents of the current table 74, i.e., writes "RESTORED", then waits for a circuit link to be connected to the XSV 60 side. Then, the XSV 60 side is set up, and faults A, B occur at a time t0. The CSV 70 side issues a request command for requesting current data from the XSV 60. In response to the request command, the XCV 60 sends current data 91 representing current data (A, B occurred, restored from C at t0) to the CSV 70. Based on the supplied current data 91, the CSV 70 produces a current table 74 and also history data 93, 94 with respect to the faults A, B. When restored from the fault A at a time t1, the XSV 60 sends event data 92 indicative of the restoration from the fault A to the CSV 70. Based on the event data 92, the CSV 70 writes "RESTORED" in the item A in the current table 74, and also writes "t1" in the restoration time of the history data 93.
As described above, when the CSV 70 side is set up, the CSV 70 clears all the contents of the current table 74 and write "RESTORED" in the current table 74. Actually, at this time, the XSV 60 has not been set up yet, and the statuses of the respective NEs are not fixed while no link is being established between the NEs and the XSV 60. Accordingly, the display of "RESTORED" on the display unit of the CSV 70 side does not properly reflect the actual statuses of the NEs. Particularly, if an actual NE corresponding to an NE registered in a data base of the CSV 70 is not operable (i.e., if a board with the NE mounted thereon is removed from the terminal station), then even after the communication link has been established, the CSV 70 is not informed of the inability of the NE to operate and interprets the NE as being normally operable.
FIG. 5 of the accompanying drawings is a timing chart of the third time sequence referred to above in which after the CSV 70 side is set up, the XSV 60 side that has once been set up is disabled and then set up again.
As shown in FIG. 5, the CSV 70 side is set up, then the XSV 60 is set up, and the CSV 70 side generates a current table 74 and also history data 103, 104 based on current data 101. Then, the XSV 60 side is disabled and set up again. At this time, the XSV 60 sends current data 102 (A, B occurred, restored from C at t1) to the CSV 70. The CSV 70 generates history data 105, 106 again based on the current data 102.
As described above, the history data 105, 106 are generated again and exist together with the history data 103, 104. To avoid the overlapping history data, it might be possible to search and check all the history data 75 for identical fault data. Since the history data 75 are actually considerably large, however, it would take a long period of time to check the history data 75 with respect to all the current data. Therefore, such a process would not be practically feasible.
As described above, the time sequences shown in FIGS. 3, 4, and 5 have problems with respect to the conventional centralized supervisory system.
As described with reference to FIG. 3, when the CSV 70 side is set up, the XSV 60 sends the event data 82 stored in the buffer memory of the XSV 60 to the CSV 70. Since the current table 74 is updated each time the event data 82 are sent to the CSV 70, the contents of the current table 74 change in order to process the past fault data that are not necessary in the present supervisory process, and the display unit of the CSV 70 side displays the past faults as they vary. Furthermore, a long period of time is required to process a large number of data from the NEs that are stored in the buffer memory. Therefore, it takes a long time until the CSV 70 side starts a supervisory process, i.e., the idle time (setting-up time) of the CSV 70 side is long.
According to another problem, as shown in FIG. 3, since the current data 81 and the stored event data 82 are transmitted, the data about the same fault B are generated as the history data 84, 86 in the history data 75.
As described with reference to FIG. 4, when the CSV 70 side is set up, the contents of the current table 74 are cleared to "RESTORED". However, the statuses of the respective NEs are not fixed before the XSV 60 side is set up and no link is established between the NEs and the XSV 60. Therefore, displaying the "RESTORED" on the display unit of the CSV 70 side does not reflect the actual NE statuses. Particularly, if an NE registered in the data base of the CSV 70 is not actually operable (i.e., if the board with the NE mounted thereon is removed), then even after the communication link has been established, the CSV 70 is not informed of the inability of the NE to operate and interprets the NE as being restored or normally operable.
As described above with reference to FIG. 5, history data are generated again together with existing history data. This drawback could be avoided by searching and checking all the history data 75 for identical or overlapping data. Since the history data 75 are considerably large, however, the time required to search all the history data 75 would be so long that such a process would not be practical.